<!doctype html>
<html lang="en">
<head>
	<meta charset="UTF-8">
	<title></title>
	<link rel="stylesheet" type="text/css" href="http://paranoid.net.cn/semantic.css" >
</head>
<body>
<section-title-en>2.14 CPU Microcode</section-title-en>
<section-title-ch>2.14 CPU微码</section-title-ch>
<p-en>
	The Intel architecture features a large instruction set. Some instructions are used infrequently, and some instructions are very complex, which makes it impractical for an execution core to handle all the instructions in hardware. Intel CPUs use a microcode table to break down rare and complex instructions into sequences of simpler instructions. Architectural extensions that only require microcode changes are significantly cheaper to implement and validate than extensions that require changes in the CPU's circuitry.
</p-en>
<p-ch>
	英特尔架构的特点是指令集很大。有些指令使用频率不高，有些指令非常复杂，这使得一个执行核心在硬件中处理所有指令是不切实际的。英特尔CPU使用微码表将罕见和复杂的指令分解成较简单的指令序列。只需要改变微码的结构扩展比需要改变CPU的电路的扩展在实现和验证上要便宜得多。
</p-ch>
<p-en>
	It follows that a good understanding of what can be done in microcode is crucial to evaluating the cost of security features that rely on architecture extensions. Furthermore, the limitations of microcode are sometimes the reasoning behind seemingly arbitrary architecture design decisions.
</p-en>
<p-ch>
	由此可见，很好地理解在微代码中可以做什么，对于评估依赖架构扩展的安全功能的成本至关重要。此外，微代码的局限性有时也是看似随意的架构设计决定背后的原因。
</p-ch>
<p-en>
	The first sub-section below presents the relevant facts pertaining to microcode in Intel's optimization reference [96] and SDM. The following subsections summarize information gleaned from Intel's patents and other researchers' findings.
</p-en>
<p-ch>
	下面第一小节介绍了英特尔优化参考[96]和SDM中有关微码的相关事实。下面几小节总结了从英特尔专利和其他研究人员的发现中收集到的信息。
</p-ch>
<subsection-title-en>2.14.1 The Role of Microcode</subsection-title-en>
<subsection-title-ch>2.14.1 微码的作用</subsection-title-ch>
<p-en>
	The frequently used instructions in the Intel architecture are handled by the core's fast path, which consists of simple decoders (§2.10) that can emit at most 4 micro-ops per instruction. Infrequently used instructions and instructions that require more than 4 micro-ops use a slower decoding path that relies on a sequencer to read micro-ops from a microcode store ROM (MSROM).
</p-en>
<p-ch>
	英特尔架构中经常使用的指令由核心的快速路径处理，它由简单的解码器(§2.10)组成，每条指令最多可以发出4个微操作。不常用的指令和需要超过4个微运算的指令使用较慢的解码路径，该路径依靠序列器从微码存储ROM（MSROM）读取微运算。
</p-ch>
<p-en>
	The 4 micro-ops limitation can be used to guess intelligently whether an architectural feature is implemented in microcode. For example, it is safe to assume that XSAVE (§2.6), which was takes over 200 micro-ops on recent CPUs [53], is most likely performed in microcode, whereas simple arithmetic and memory accesses are handled directly by hardware.
</p-en>
<p-ch>
	4微操作的限制可以用来智能地猜测一个架构功能是否在微代码中实现。例如，可以肯定的是，XSAVE (§2.6)，在最近的CPU上需要超过200个微操作[53]，很可能是在微代码中执行的，而简单的算术和内存访问则直接由硬件处理。
</p-ch>
<p-en>
	The core's execution units handle common cases in fast paths implemented in hardware. When an input cannot be handled by the fast paths, the execution unit issues a microcode assist, which points the microcode sequencer to a routine in microcode that handles the edge cases. The most common cited example in Intel's documentation is floating point instructions, which issue assists to handle denormalized inputs.
</p-en>
<p-ch>
	核心的执行单元在硬件实现的快速路径中处理常见的情况。当一个输入不能被快速路径处理时，执行单元会发出一个微码辅助，将微码排序器指向微码中处理边缘情况的例程。在英特尔的文档中，最常引用的例子是浮点指令，它发出助记来处理去正常化的输入。
</p-ch>
<p-en>
	The REP MOVS family of instructions, also known as string instructions because of their use in strcpy-like functions, operate on variable-sized arrays. These instructions can handle small arrays in hardware, and issue microcode assists for larger arrays.
</p-en>
<p-ch>
	REP MOVS系列指令，因为在类似strcpy的函数中使用，所以也被称为字符串指令，对可变大小的数组进行操作。这些指令可以在硬件中处理小的数组，并对大的数组发出微码辅助。
</p-ch>
<p-en>
	Modern Intel processors implement a microcode update facility. The SDM describes the process of applying microcode updates from the perspective of system software. Each core can be updated independently, and the updates must be reapplied on each boot cycle. A core can be updated multiple times. The latest SDM at the time of this writing states that a microcode update is up to 16 KB in size.
</p-en>
<p-ch>
	现代英特尔处理器实现了微码更新设施。SDM从系统软件的角度描述了应用微码更新的过程。每个内核可以独立更新，更新必须在每个启动周期重新应用。一个内核可以被更新多次。在撰写本文时，最新的SDM规定，一次微码更新的大小为16KB。
</p-ch>
<p-en>
	Processor engineers prefer to build new architectural features as microcode extensions, because microcode can be iterated on much faster than hardware, which reduces development cost [193, 194]. The update facility further increases the appeal of microcode, as some classes of bugs can be fixed after a CPU has been released.
</p-en>
<p-ch>
	处理器工程师更喜欢将新的架构功能作为微代码扩展来构建，因为微代码的迭代速度比硬件快得多，从而降低了开发成本[193，194]。更新设施进一步增加了微代码的吸引力，因为一些类别的错误可以在CPU发布后修复。
</p-ch>
<p-en>
	Intel patents [110, 138] describing Software Guard Extensions (SGX) disclose that SGX is entirely implemented in microcode, except for the memory encryption engine. A description of SGX's implementation could provide great insights into Intel's microcode, but, unfortunately, the SDM chapters covering SGX do not include such a description. We therefore rely on other public information sources about the role of microcode in the security-sensitive areas covered by previous sections, namely memory management (§2.5, §2.11.5), the handling of hardware exceptions (§2.8.2) and interrupts (§2.12), and platform initialization (§2.13).
</p-en>
<p-ch>
	英特尔描述软件卫士扩展(SGX)的专利[110，138]披露，除了内存加密引擎外，SGX完全用微代码实现。对SGX的实现的描述可以为我们了解英特尔的微代码提供很大的帮助，但遗憾的是，涉及SGX的SDM章节并没有包含这样的描述。因此，我们依靠其他公开的信息来源来了解微代码在前几节所涉及的安全敏感领域的作用，即内存管理（§2.5、§2.11.5）、硬件异常的处理（§2.8.2）和中断（§2.12）以及平台初始化（§2.13）。
</p-ch>
<p-en>
	The use of microcode assists can be measured using the Precise Event Based Sampling (PEBS) feature in recent Intel processors. PEBS provides counters for the number of micro-ops coming from MSROM, including complex instructions and assists, counters for the numbers of assists associated with some micro-op classes (SSE and AVX stores and transitions), and a counter for assists generated by all other micro-ops.
</p-en>
<p-ch>
	可以使用最近英特尔处理器中的精确事件采样(PEBS)功能来测量微码助记的使用情况。PEBS提供了来自MSROM的微操作数量的计数器，包括复杂的指令和辅助，与某些微操作类（SSE和AVX存储和转换）相关的辅助数量的计数器，以及所有其他微操作产生的辅助的计数器。
</p-ch>
<p-en>
	The PEBS feature itself is implemented using microcode assists (this is implied in the SDM and confirmed by [120]) when it needs to write the execution context into a PEBS record. Given the wide range of features monitored by PEBS counters, we assume that all execution units in the core can issue microcode assists, which are performed at micro-op retirement. This finding is confirmed by an Intel patent [24], and is supported by the existence of a PEBS counter for the “number of microcode assists invoked by hardware upon micro-op writeback.”
</p-en>
<p-ch>
	PEBS功能本身是在需要将执行上下文写入PEBS记录时，使用微码助攻来实现的（这一点在SDM中隐含，并得到[120]的证实）。考虑到PEBS计数器监测的功能范围很广，我们假设核心中的所有执行单元都可以发出微码辅助，微码辅助是在微操作退休时执行的。英特尔的一项专利[24]证实了这一结论，并且支持这一结论的是 "微操作退役时硬件调用的微代码辅助次数 "的PEBS计数器的存在。
</p-ch>
<p-en>
	Intel's optimization manual describes one more interesting assist, from a memory system perspective. SIMD masked loads (using VMASKMOV) read a series of data elements from memory into a vector register. A mask register decides whether elements are moved or ignored. If the memory address overlaps an invalid page (e.g., the P flag is 0, §2.5), a microcode assist is issued, even if the mask indicates that no element from the invalid page should be read. The microcode checks whether the elements in the invalid page have the corresponding mask bits set, and either performs the load or issues a page fault.
</p-en>
<p-ch>
	英特尔的优化手册从内存系统的角度，描述了一个比较有趣的辅助。SIMD掩码加载（使用VMASKMOV）从内存中读取一系列数据元素到一个向量寄存器中。掩码寄存器决定元素是被移动还是被忽略。如果存储器地址与无效页重叠(如P标志为0，×2.5)，则发出微码辅助，即使掩码表明不应读取无效页的元素。微码检查无效页中的元素是否设置了相应的掩码位，并执行加载或发出页面故障。
</p-ch>
<p-en>
	The description of machine checks in the SDM mentions page assists and page faults in the same context. We assume that the page assists are issued in some cases when a TLB miss occurs (§2.11.5) and the PMH has to walk the page table. The following section develops this assumption and provides supporting evidence from Intel's assigned patents and published patent applications.
</p-en>
<p-ch>
	在SDM中对机器检查的描述中，在同样的上下文中提到了页面协助和页面故障。我们假设在某些情况下，当发生TLB失误时（§2.11.5），PMH必须走页表，就会发出页辅助。下文将发展这一假设，并提供来自英特尔转让的专利和已公布的专利申请的支持证据。
</p-ch>
<subsection-title-en>2.14.2 Microcode Structure</subsection-title-en>
<subsection-title-ch>2.14.2 微码结构</subsection-title-ch>
<p-en>
	According to a 2013 Intel patent [83], the avenues considered for implementing new architectural features are a completely microcode-based implementation, using existing micro-ops, a microcode implementation with hardware support, which would use new micro-ops, and a complete hardware implementation, using finite state machines (FSMs).
</p-en>
<p-ch>
	根据英特尔2013年的一项专利[83]，考虑实现新架构功能的途径有：完全基于微代码的实现，使用现有的微操作系统；带有硬件支持的微代码实现，将使用新的微操作系统；以及完全的硬件实现，使用有限状态机（FSM）。
</p-ch>
<p-en>
	The main component of the MSROM is a table of micro-ops [193, 194]. According to an example in a 2012 Intel patent [194], the table contains on the order of 20,000 micro-ops, and a micro-op has about 70 bits. On embedded processors, like the Atom, microcode may be partially compressed [193, 194].
</p-en>
<p-ch>
	MSROM的主要组成部分是一个微操作表[193，194]。根据2012年英特尔专利[194]中的一个例子，该表包含了大约20,000个微操作，而一个微操作大约有70位。在嵌入式处理器上，比如Atom，微码可以被部分压缩[193，194]。
</p-ch>
<p-en>
	The MSROM also contains an event ROM, which is an array of pointers to event handling code in the micro-ops table [160]. Microcode events are hardware exceptions, assists, and interrupts [24, 36, 149]. The processor described in a 1999 patent [160] has a 64-entry event table, where the first 16 entries point to hardware exception handlers and the other entries are used by assists.
</p-en>
<p-ch>
	MSROM还包含一个事件ROM，它是一个指向微码表中事件处理代码的指针数组[160]。微码事件是硬件异常、辅助和中断[24，36，149]。1999年的一项专利[160]中描述的处理器有一个64个条目的事件表，其中前16个条目指向硬件异常处理程序，其他条目由辅助程序使用。
</p-ch>
<p-en>
	The execution units can issue an assist or signal a fault by associating an event code with the result of a micro-op. When the micro-op is committed (§2.10), the event code causes the out-of-order scheduler to squash all the micro-ops that are in-flight in the ROB. The event code is forwarded to the microcode sequencer, which reads the micro-ops in the corresponding event handler [24, 149].
</p-en>
<p-ch>
	执行单元可以通过将一个事件代码与微操作的结果关联起来，发出协助或故障信号。当微操作被提交时(§2.10)，事件代码会使失序调度器压制ROB中所有在飞的微操作。事件代码被转发到微码排序器，后者在相应的事件处理程序中读取微操作[24，149]。
</p-ch>
<p-en>
	The hardware exception handling logic (§2.8.2) and interrupt handling logic (§2.12) is implemented entirely in microcode [149]. Therefore, changes to this logic are relatively inexpensive to implement on Intel processors. This is rather fortunate, as the Intel architecture's standard hardware exception handling process requires that the fault handler is trusted by the code that encounters the exception (§2.8.2), and this assumption cannot be satisfied by a design where the software executing inside a secure container must be isolated from the system software managing the computer's resources.
</p-en>
<p-ch>
	硬件异常处理逻辑(§2.8.2)和中断处理逻辑(§2.12)完全在微代码中实现[149]。因此，在英特尔处理器上实现这些逻辑的改变相对来说是比较便宜的。这是相当幸运的，因为英特尔架构的标准硬件异常处理过程要求故障处理程序被遇到异常的代码所信任(§2.8.2)，而在安全容器内执行的软件必须与管理计算机资源的系统软件隔离的设计无法满足这一假设。
</p-ch>
<p-en>
	The execution units in modern Intel processors support microcode procedures, via dedicated microcode call and return micro-ops [36]. The micro-ops manage a hardware data structure that conceptually stores a stack of microcode instruction pointers, and is integrated with out-of-order execution and hardware exceptions, interrupts and assists.
</p-en>
<p-ch>
	现代英特尔处理器中的执行单元支持微码程序，通过专用的微码调用和返回微操作[36]。微操作管理着一个硬件数据结构，该结构在概念上存储了一个微码指令指针的堆栈，并与失序执行和硬件异常、中断和辅助集成。
</p-ch>
<p-en>
	Asides from special micro-ops, microcode also employs special load and store instructions, which turn into special bus cycles, to issue commands to other functional units [159]. The memory addresses in the special loads and stores encode commands and input parameters. For example, stores to a certain range of addresses flush specific TLB sets.
</p-en>
<p-ch>
	除了特殊的微操作外，微代码还采用特殊的加载和存储指令，变成特殊的总线周期，向其他功能单元发出指令[159]。特殊加载和存储中的存储器地址对命令和输入参数进行编码。例如，存储到一定范围的地址可以冲刷特定的TLB集。
</p-ch>
<subsection-title-en>2.14.3 Microcode and Address Translation</subsection-title-en>
<subsection-title-ch>2.14.3 微码和地址转换</subsection-title-ch>
<p-en>
	Address translation (§2.5) is configured by CR3, which stores the physical address of the top-level page table, and by various bits in CR0 and CR4, all of which are described in the SDM. Writes to these control registers are implemented in microcode, which stores extra information in microcode-visible registers [62].
</p-en>
<p-ch>
	地址转换(§2.5)由CR3配置，CR3存储顶层页表的物理地址，CR0和CR4中的各种位配置，所有这些位在SDM中都有描述。对这些控制寄存器的写入是在微码中实现的，微码将额外的信息存储在微码可见的寄存器中[62]。
</p-ch>
<p-en>
	When a TLB miss (§2.11.5) occurs, the memory execution unit forwards the virtual address to the Page Miss Handler (PMH), which performs the page walk needed to obtain a physical address. In order to minimize the latency of a page walk, the PMH is implemented as a Finite-State Machine (FSM) [78, 154]. Furthermore, the PMH fetches the page table entries from memory by issuing “stuffed loads”, which are special micro-ops that bypass the reorder buffer (ROB) and go straight to the memory execution units (§2.10), thus avoiding the overhead associated with out-of-order scheduling [63, 78, 159].
</p-en>
<p-ch>
	当TLB缺失(§2.11.5)发生时，内存执行单元将虚拟地址转发到页面缺失处理程序(PMH)，PMH执行获取物理地址所需的页面行走。为了最小化走页的延迟，PMH被实现为有限状态机（FSM）[78，154]。此外，PMH通过发出 "填充负载 "从内存中获取页表条目，这是一种特殊的微操作，它绕过重排序缓冲区(ROB)，直接进入内存执行单元(§2.10)，从而避免了与失序调度相关的开销[63，78，159]。
</p-ch>
<p-en>
	The FSM in the PMH handles the fast path of the entire address translation process, which assumes no address translation fault (§2.8.2) occurs [63, 64, 149, 160], and no page table entry needs to be modified [63].
</p-en>
<p-ch>
	PMH中的FSM处理整个地址翻译过程的快速路径，它假设没有发生地址翻译故障（§2.8.2）[63，64，149，160]，不需要修改页表条目[63]。
</p-ch>
<p-en>
	When the PMH FSM detects the conditions that trigger a Page Fault or a General Protection Fault, it communicates a microcode event code, corresponding to the detected fault condition, to the execution unit (§2.10) responsible for memory operations [63, 64, 149, 160]. In turn, the execution unit triggers the fault by associating the event code with the micro-op that caused the address translation, as described in the previous section.
</p-en>
<p-ch>
	当PMH FSM检测到触发页故障或一般保护故障的条件时，它将与检测到的故障条件相对应的微码事件代码传达给负责存储器操作的执行单元(§2.10)[63，64，149，160]。反过来，执行单元通过将事件代码与引起地址转换的微操作相关联，触发故障，如上节所述。
</p-ch>
<p-en>
	The PMH FSM does not set the Accessed or Dirty attributes (§2.5.3) in page table entries. When it detects that a page table entry must be modified, the FSM issues a microcode event code for a page walk assist [63]. The microcode handler performs the page walk again, setting the A and D attributes on page table entries when necessary [63]. This finding was indirectly confirmed by the description for a PEBS event in the most recent SDM release.
</p-en>
<p-ch>
	PMH FSM不设置页表条目中的Accessed或Dirty属性（§2.5.3）。当它检测到一个页表条目必须被修改时，FSM会发出一个微码事件代码来进行页面行走辅助[63]。微码处理程序再次执行走页，必要时设置页表项的A和D属性[63]。最新的SDM版本中对PEBS事件的描述间接证实了这一发现。
</p-ch>
<p-en>
	The patents at the core of our descriptions above [24, 63, 64, 149, 160] were all issued between 1996 and 1999, which raises the concern of obsolescence. As Intel would not be able to file new patents for the same specifications, we cannot present newer patents with the information above. Fortunately, we were able to find newer patents that mention the techniques described above, proving their relevance to newer CPU models.
</p-en>
<p-ch>
	我们上述描述的核心专利[24、63、64、149、160]都是在1996年到1999年之间发布的，这就引起了人们对过时的担忧。由于英特尔将无法为同样的规格申请新的专利，因此我们无法用上述信息来介绍较新的专利。幸运的是，我们能够找到提到上述技术的较新专利，证明它们与较新的CPU型号有关。
</p-ch>
<p-en>
	Two 2014 patents [78, 154] mention that the PMH is executing a FSM which issues stuffing loads to obtain page table entries. A 2009 patent [62] mentions that microcode is invoked after a PMH walk, and that the microcode can prevent the translation result produced by the PMH from being written to the TLB.
</p-en>
<p-ch>
	2014年的两项专利[78，154]提到，PMH正在执行一个FSM，FSM会发出填充载荷来获取页表条目。2009年的一项专利[62]提到，在PMH行走后调用微代码，微代码可以防止PMH产生的翻译结果被写入TLB。
</p-ch>
<p-en>
	A 2013 patent [83] and a 2014 patent [155] on scatter / gather instructions disclose that the newly introduced instructions use a combination of hardware in the execution units that perform memory operations, which include the PMH. The hardware issues microcode assists for slow paths, such as gathering vector elements stored in uncacheable memory (§2.11.4), and operations that cause Page Faults.
</p-en>
<p-ch>
	关于散布/收集指令的2013年专利[83]和2014年专利[155]披露，新引入的指令在执行单元中使用了执行内存操作的硬件组合，其中包括PMH。硬件为慢速路径发出微代码辅助，例如收集存储在不可缓存内存中的向量元素(§2.11.4)，以及导致Page Faults的操作。
</p-ch>
<p-en>
	A 2014 patent on APIC (§2.12) virtualization [168] describes a memory execution unit modification that invokes a microcode assist for certain memory accesses, based on the contents of some range registers. The patent also mentions that the range registers are checked when the TLB miss occurs and the PMH is invoked, in order to decide whether a fast hardware path can be used for APIC virtualization, or a microcode assist must be issued.
</p-en>
<p-ch>
	2014年一项关于APIC(§2.12)虚拟化的专利[168]描述了一种内存执行单元的修改，根据一些范围寄存器的内容，对某些内存访问调用微码辅助。该专利还提到，当TLB失误发生时，会检查范围寄存器，并调用PMH，以决定是否可以使用快速硬件路径进行APIC虚拟化，或者必须发出微码辅助。
</p-ch>
<p-en>
	The recent patents mentioned above allow us to conclude that the PMH in recent processors still relies on an FSM and stuffed loads, and still uses microcode assists to handle infrequent and complex operations. This assumption plays a key role in estimating the implementation complexity of architectural modifications targeting the processor's address translation mechanism.
</p-en>
<p-ch>
	上面提到的最近的专利让我们得出结论，最近的处理器中的PMH仍然依赖于FSM和塞满负载，并且仍然使用微代码辅助来处理不频繁和复杂的操作。这个假设在估计针对处理器地址转换机制的架构修改的实现复杂度方面起到了关键作用。
</p-ch>
<subsection-title-en>2.14.4 Microcode and Booting</subsection-title-en>
<subsection-title-ch>2.14.4 微码和启动</subsection-title-ch>
<p-en>
	The SDM states that microcode performs the Built-In Self Test (BIST, §2.13.2), but does not provide any details on the rest of the CPU's hardware initialization.
</p-en>
<p-ch>
	SDM指出，微代码执行内置自检(BIST，§2.13.2)，但没有提供CPU其余硬件初始化的任何细节。
</p-ch>
<p-en>
	In fact, the entire SEC implementation on Intel platforms is contained in the processor microcode [40, 41, 168]. This implementation has desirable security properties, as it is significantly more expensive for an attacker to tamper with the MSROM circuitry (§2.14.2) than it is to modify the contents of the flash memory chip that stores the UEFI firmware. §3.4.3 and §3.6 describe the broad classes of attacks that an Intel platform can be subjected to.
</p-en>
<p-ch>
	事实上，英特尔平台上的整个SEC实现都包含在处理器微代码中[40，41，168]。这种实现具有理想的安全特性，因为对于攻击者来说，篡改MSROM电路(§2.14.2)比修改存储UEFI固件的闪存芯片内容的成本要高得多。 §3.4.3和§3.6描述了英特尔平台可能遭受的广泛攻击类别。
</p-ch>
<p-en>
	The microcode that implements SEC performs MP initialization (§2.13.2), as suggested in the SDM. The microcode then places the BSP into Cache-as-RAM (CAR) mode, looks up the PEI Authenticated Code Module (ACM) in the Firmware Interface Table (FIT), loads the PEI ACM into the cache, and verifies its signature (§2.13.2) [40, 41, 144, 202, 203]. Given the structure of ACM signatures, we can conclude that Intel's microcode contains implementations of RSA decryption and of a variant of SHA hashing.
</p-en>
<p-ch>
	实现SEC的微代码按照SDM的建议执行MP初始化（§2.13.2）。然后，微代码将BSP置于Cache-as-RAM(CAR)模式，在固件接口表(FIT)中查找PEI认证代码模块(ACM)，将PEI ACM加载到缓存中，并验证其签名(§2.13.2)[40，41，144，202，203]。考虑到ACM签名的结构，我们可以得出结论，英特尔的微代码包含了RSA解密和SHA散列的变体的实现。
</p-ch>
<p-en>
	The PEI ACM is executed from the CPU's cache, after it is loaded by the microcode [40, 41, 202]. This removes the possibility for an attacker with physical access to the SPI flash chip to change the firmware's contents after the microcode computes its cryptographic hash, but before it is executed.
</p-en>
<p-ch>
	PEI ACM在被微代码加载后，从CPU的缓存中执行[40，41，202]。这就消除了能够物理访问SPI闪存芯片的攻击者在微代码计算出其加密哈希值后，但在执行之前改变固件内容的可能性。
</p-ch>
<p-en>
	On motherboards compatible with LaGrande Server Extensions (LT-SX, also known as Intel TXT for servers), the firmware implementing PEI verifies that each CPU connected to motherboard supports LT-SX, and powers off the CPU sockets that don't hold processors that implement LT-SX [144]. This prevents an attacker from tampering with a TXT-protected VM by hot-plugging a CPU in a running computer that is inside TXT mode. When a hot-plugged CPU passes security tests, a hypervisor is notified that a new CPU is available. The hypervisor updates its internal state, and sends the new CPU a SIPI. The new CPU executes a SIPI handler, inside microcode, that configures the CPU's state to match the state expected by the TXT hypervisor [144]. This implies that the AP initialization described in §2.13.2 is implemented in microcode.
</p-en>
<p-ch>
	在兼容LaGrande服务器扩展(LT-SX，也就是服务器的英特尔TXT)的主板上，实现PEI的固件会验证连接到主板上的每个CPU是否支持LT-SX，并关闭不容纳实现LT-SX的处理器的CPU插座[144]。这样可以防止攻击者通过热插拔正在运行的计算机中的CPU来篡改TXT保护的虚拟机，该虚拟机处于TXT模式内。当热插拔的CPU通过安全测试时，管理程序会被通知有新的CPU可用。管理程序更新其内部状态，并向新CPU发送一个SIPI。新的CPU在微代码内部执行一个SIPI处理程序，将CPU的状态配置为与TXT管理程序所期望的状态相匹配[144]。这意味着§2.13.2中描述的AP初始化是在微代码中实现的。
</p-ch>
<subsection-title-en>2.14.5 Microcode Updates</subsection-title-en>
<subsection-title-ch>2.14.5 微码更新</subsection-title-ch>
<p-en>
	The SDM explains that the microcode on Intel CPUs can be updated, and describes the process for applying an update. However, no detail about the contents of an update is provided. Analyzing Intel's microcode updates seems like a promising avenue towards discovering the microcode's structure. Unfortunately, the updates have so far proven to be inscrutable [32].
</p-en>
<p-ch>
	SDM解释了英特尔CPU上的微代码可以更新，并描述了申请更新的过程。然而，没有提供关于更新内容的细节。分析英特尔的微代码更新似乎是一个很有希望的途径，可以发现微代码的结构。不幸的是，到目前为止，更新被证明是不可捉摸的[32]。
</p-ch>
<p-en>
	The microcode updates cannot be easily analyzed because they are encrypted, hashed with a cryptographic hash function like SHA-256, and signed using RSA or elliptic curve cryptography [202]. The update facility is implemented entirely in microcode, including the decryption and signature verification [202].
</p-en>
<p-ch>
	微码更新不容易被分析，因为它们被加密，用SHA-256等加密散列函数进行哈希，并使用RSA或椭圆曲线加密技术进行签名[202]。更新设施完全在微码中实现，包括解密和签名验证[202]。
</p-ch>
<p-en>
	[75] independently used fault injection and timing analysis to conclude that each recent Intel microcode update is signed with a 2048-bit RSA key and a (possibly non-standard) 256-bit hash algorithm, which agrees with the findings above.
</p-en>
<p-ch>
	[75]独立使用故障注入和时序分析得出结论，最近的每一次英特尔微码更新都是用2048位RSA密钥和（可能是非标准的）256位哈希算法签名的，这与上述结论一致。
</p-ch>
<p-en>
	The microcode update implementation places the core's cache into No-Evict Mode (NEM, documented by the SDM) and copies the microcode update into the cache before verifying its signature [202]. The update facility also sets up an MTRR entry to protect the update's contents from modifications via DMA transfers [202] as it is verified and applied.
</p-en>
<p-ch>
	微码更新实现将内核的缓存置入No-Evict模式（NEM，由SDM记录），并在验证其签名之前将微码更新复制到缓存中[202]。更新设施还设置了一个MTRR条目，以保护更新的内容在验证和应用时不被通过DMA传输修改[202]。
</p-ch>
<p-en>
	While Intel publishes the most recent microcode updates for each of its CPU models, the release notes associated with the updates are not publicly available. This is unfortunate, as the release notes could be used to confirm guesses that certain features are implemented in microcode.
</p-en>
<p-ch>
	虽然英特尔公布了其每个CPU型号的最新微代码更新，但与更新相关的发布说明却没有公开。这是很不幸的，因为发布说明可以用来确认某些功能在微代码中实现的猜测。
</p-ch>
<p-en>
	However, some information can be inferred by reading through the Errata section in Intel's Specification Updates [88, 104, 106]. The phrase “it is possible for BIOS5 to contain a workaround for this erratum” generally means that a microcode update was issued. For example, Errata AH in [88] implies that string instructions (REP MOV) are implemented in microcode, which was confirmed by Intel [12].
</p-en>
<p-ch>
	然而，通过阅读Intel的规范更新[88，104，106]中的勘误部分可以推断出一些信息。"BIOS5有可能包含一个解决此错误的方法 "这句话一般意味着发布了一个微代码更新。例如，[88]中的 Errata AH 意味着字符串指令 (REP MOV) 是在微代码中实现的，这一点已被 Intel [12] 证实。
</p-ch>
<p-en>
	Errata AH43 and AH91 in [88], and AAK73 in [104] imply that address translation (§2.5) is at least partially implemented in microcode. Errata AAK53, AAK63, and AAK70, AAK178 in [104], and BT138, BT210, in [106] imply that VM entries and exits (§2.8.2) are implemented in microcode, which is confirmed by the APIC virtualization patent [168].
</p-en>
<p-ch>
	[88]中的勘误表AH43和AH91以及[104]中的AAK73意味着地址转换(§2.5)至少部分在微码中实现。勘误表AAK53、AAK63和[104]中的AAK70、AAK178，以及[106]中的BT138、BT210意味着虚拟机的进入和退出(§2.8.2)是在微代码中实现的，这一点得到了APIC虚拟化专利[168]的证实。
</p-ch>

</body>
</html>	